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Abstract 



The computer controlled financial transaction system has a customer unit A1 0, a dealer unit A20 and a 
finance controller A3U that are coupled together by a data bus A6a,b,cU that provides a secure transfer of 
data. A contract module A8U as a specific finance module is connected by adapters A10U. The customer 
unit has a selection module A140 that is software based for specific finance systems. 
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(54) Verfahren zur rechnergestOtzten ZahlungsabwicWung Qber Zahlungssysteme 

(57) Die Erfindung bezeichnet ein Verfahren zur 
rechnergestOtzten ZahlungsabwicWung Qber Zahlungs- 
systeme unter der Zwtschenschartung eines Finanz- 
dienstleisters (3) der dieses Zahlungssystem (4) 
unterstOtzt, wobei eine sichere Obertragung von Daten 
Qber Datenvertindungen (6a), (6b), (6c) in Netzen (5) 
gewahrleistet wird. Die Aufgabe besteht darin, dem 
Handler (2) mehrere fur den Kunden (1) mOgliche Zah- 
lungssysteme (4) zur Verfugung zu stellen, ohne den 
Handler (2) selbst zur Integration dieser Zahlungssy- 
steme (4) zu zwingen. Dies wird geldst, indem von 
einem Vertragsmodul (8) des Finanzdienstleisters (3) 
dem Handler (2) ein neutral es Handler- Vertragsproto- 
koll (19) zur VerfOgung gestellt wird, uber welches eine 
beidseitige Verpf Bchtung zwtschen dem Handler (2) und 
dem Kunden (1) abgeschlossen und diese dem Ver- 
tragsmodul (8) QbermrtteK wird. In den weiteren Verfah- 
rensschrrtten wird die ZahlungsabwicWung des Kunden 
(1) in seinem speziellen Zahlungssystem (4) sicherge- 
stelrt und dessen Status dem Handler (5) Gbermittert. 
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Beschreibung 

[0001] Die Erfindung bezeichnet ein Verfahren zur 
rechnergestutzten Zahlungsabwickfung uber Zahlungs- 
systeme, betreffend einer beidseitigen Verpflichtung, s 
insbesondere eines Kaufvertrages, zwischen einem 
Kunden und einem Handler unter der Zwischenschal- 
tung eines Finanzdienstleisters, insbesondere einer 
Bank, der dieses Zahlungssystem unterstOtzt, wobei 
durch spezielle Ubertragungssysteme eine sichere 10 
Ubertragung von Daten uber Datenverbindungen in 
Netzen gewShrleistet wird. 

[0002] Ublicherweise bietet ein Handler den Kunden 
bestimmte Waren an, die der Kunde auswdhft. Hat sich 
der Kunde zum Kauf entschtossen, kommt es zum is 
Abschlufl eines Kaufvertrages zwischen dem Kunden 
und dem Handler. In Folge des Vertrages zahlt der 
Kunde in einem Zahlungsverfahren (bsw. durch Barzah- 
lung) den Kaufpreis und der Handler ubergibt die ver- 
kaufte Ware. 20 
[0003] Eine modrf izierte Variarrte dieses Zahlungsver- 
fahrens stellt der Kauf uber Kreditkarten oder uber ahn- 
liche Zahlungssysteme dar. Dabei wird etn 
Zahlungssystembetreiber, zumeist eine Bank, zwischen 
den Handler und den Kunden geschattet Der Kunde 25 
bezahlt demnach nicht direkt, sondern der Zahlungssy- 
stembetreiber burgt (mrttels der Kredrtkarte) fur die Zah- 
lungsfahigkert des Kunden. Zu einem spateren 
Zertpunkt bucht der Zahlungssystembetreiber den faili- 
gen Kaufpreis vom Konto des Kunden ab und uberweist 30 
den Kaufpreis auf das Konto des Handlers. Fur diesen 
Vorgang verlangt er ublicherweise eine Gebuhr. In der 
Praxis sind unterschiedliche Zahlungssysteme mit ver- 
schiedenen Konditionen fur unterschiedliche Einsatz- 
zwecke notwendig. 35 
[0004] Viele moderne Zahlungssysteme sind als Son- 
derfunktionen von OVA (Datenverarbertungsarrfagen) 
rechnergestutzt ausfuhrbar (IPC G06F 17/60). Dieser 
technische Hirrtergrund wird beispielsweise in der 
Druckschrift EP OS 0668 579 A2 im Zusammenhang 40 
mit Keditkarten und in der Druckschrift WO 95/19010 im 
Zusammenhang mrt Homebankingsystemen erwdhnt 
Diese unterschiedlichen Zahlungssysteme der einzel- 
nen Zahlungssystembetreiber sind jeweils modtfiziert 
und in der Regel untereinander nicht oder nur einge- 4s 
schrankt kompatibel. BezOgtich des inter nationalen 
Zahlungsverkehrs sind nationaJe Zahlungsmrttel men- 
genmaGig verbreiteter als einzelne intemationale Zah- 
lungssysteme. 

[0005] Moderne Ubertragungssysteme fur Irrformatio- so 
nen fQr Datenverbindungen im Femverkehr (IPC H04L), 
beispielsweise das Internet, ermOgiichen die Werbung 
des Handlers uber diese Ubertragungssysteme. Dazu 
bietet der Handler eine Werbeinformation an, uber weJ- 
che er seine Waren pr&sentiert. Mrttels eines vorgefer- 55 
tigten Kaufvertrages kann der Kunde bequem den 
Kaufvertrag rechtskrdftig werden lassen, indem er den 
unterschriebenen Kaufvertrag an den Handler sendet 



beispielsweise per Post, per Fax oder uber andere 
(rechtlich anerkannte) elektronische Ubertragungssy- 
steme. 

[0006] Bei der Ubermrttlung von Daten (persOnliche 
Informationen aus Kaufvertrdgen, Einzelherten der Zah- 
lungsabwickfung) auf modernen Ubertragungssyste- 
men (z.B. im Internet) besteht jedoch die Gefahr der 
unberechtigten Kenntnis, Benutzung oder Modifizierung 
dieser Daten. Aus diesem Grund wurden kryptographi- 
sche Verfahren entwickelt, die auch auf elektronischen 
Wege eine sichere Ubertragung, das heiBt sicher vor 
Manipulation und Zugriff, von Daten zwischen zwei Teil- 
nehmern ermOglichen (IPC H04L 9/00). Dieser techni- 
sche Hintergrund wird bsw. in der Druckschrift WO 
97/16779 im Zusammenhang mit der Eingabesicherung 
und Informationsubertragung sowie in der Druckschrift 
EP OS 0668 580 A1 im Zusammenhang mit der 
Authentisierung der Teilnehmer erwahnt. 
[0007] Derartige kryptographische Verfahren werden 
jeweils in einem spezrfischen Zahlungsmodul realisiert 
und kdnnen Hardware basierend und Software baste- 
rend sein. Im ersten Fall benotigt jeder Teilnehmer eine 
(gunstig individuelle) Hardware zur Ver- und Entschlus- 
selung der Daten. Im zweiten Fall wird dies bei zumin- 
dest einem Teilnehmer durch identische Hardware mit 
(gunstig individuellen) verschlusselten Parametern 
erziett (andern sich zumeist in der Zeitspanne einer 
mOglichen EntschlQsselung dieser). Bei Finanzdienst- 
leistern, insbesondere bei Banken, ist eine rechnerge- 
stutzte Zahlungsabwickfung (IPC G06F 19/00) bei 
modernen Ubertragungssystemen (z.B. im Internet) nur 
Ansatzweise mit spezifischen Zahlungssystemen eta- 
bliert (z.B. SET(secure electronic transition)). 
[0008] Durch die vielfaitigen MOglichkeiten zum 
AbschluB eines Vertrages zwischen dem Kunden und 
dem Handler, insbesondere auf elektronischem Wege, 
hat der Kunde die MOglichkeit, zwischen den verschie- 
denen Zahlungsverfahren (Barzahlung per Nach- 
nahme, Oberweisung, Laslschrift, Kredrtkarte, ...), den 
mOglichen Zahlungssystemen (z.B. VISA-Card; EC- 
Kreditkarte; SET PIN/TAN(personai identity num- 
ber/transaction indetity number), Geldkarte, ...) und den 
damit verbundenen Konditionen auszuwdhlen. Dies 
setzt jedoch voraus, da6 der Handler diese Zahlungs- 
verfahren und Zahlungssysteme anbietet 
[0009] Im Interesse der Kundenaientierung ist der 
Handler in der Regel bemuht, samtliche Zahlungsver- 
fahren und Zahlungssysteme anzubieten. Dieses 
Bemuhen bedingt jedoch fQr den Handler notwendig die 
Integration dieser Zahlungssysteme, verbunden mit 
einem groBen organisatortschen Aufwand (z.B. jeweils 
verschiedene Konten), Unkosten (for die Teilnahme an 
den jeweiligen Zahlungssystemen), einem hohen 
Kostenrisiko und der Notwendigkert, die notwendigen 
Mittel fQr die entsprechenden Zahlungssysteme (Kredit- 
kartenleser, Zahlungsmodule) stets einsatzberert zur 
VerfOgung zu halten. Aus diesen GrOnden sind Zah- 
lungssysteme fQr Handler sehr kompliziert integrierbar 
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und neu entwickelte schwer in groBem MaBstab einzu- 
fuhren. 

[0010] Die Aufgabe der Erfindung ist es, ein oben 
beschriebenes Verfahren zur rechnergestutzten Zah- 
lungsabwicklung uber Zahlungssysteme zu entwickeln, 
welche die aufgefOhrten Nachteile besertigt und dem 
Handler mehrere for den Kunden mOgliche Zahlungssy- 
steme zur Verfugung stellt, ohne den Handler selbst zur 
Integration dieser Zahlungssysteme zu zwingen. 
[001 1 ] Die Aufgabe wird durch die im Patentanspruch 
1 aufgefOhrten Merkmale gelOst. Bevorzugte Weiterbil- 
dungen ergeben sich aus den Unteranspruchen. 
[0012] Das Wesen der Erfindung besteht darin, da 3 
uber eine geschlossene Datenverbindung uber Netze 
ineinem 1. Schritt 

der Kunde seine gewunschten Waren und Zahlungssy- 
steme dem Handler uber die Datenverbindung mttteilt 
und danach durch den Handler die Kundeninitialisie- 
rung des Kunden erfolgt, 
in einen 2. Schritt 

der Handler uber eine Datenverbindung zu einem Ver- 
tragsmodul bei einem Rnanzdienstleister die Konditio- 
nen fur die gewunschten Zahlungssysteme abfragt und 
dieses sie ihm sicher Gbermittelt, 
in einem 3. Schritt 

der Handler uber die Datenverbindung dem Kunden 
sicher ein Auswahl-Modul ubermittert, welches, jeweils 
einzeln fur die gewunschten und verfugbaren Zahlungs- 
systeme, das konkrete Angebot des Handlers an den 
Kunden beinhartet, 
in einem 4. Schritt 

der Kunde ein einzeines konkretes Angebot des Hand- 
lers im Auswahl-Modul auswahlt und damit eine beidsei- 
tige Verpflichtung eingeht, deren Inhatt das Auswahl- 
Modul sicher uber die Datenverbindung dem Handler 
und sicher uber die Datenverbindung dem Vertragsmo- 
dut Gbermittelt, welches sie auf ihre Richtigkeit uber- 
pruft und unter der eindeutigen ProzeBnummer 
speichert. 
in einem 5. Schritt 

das Auswahl-Modul die fur das ausgewahtte spezrfische 
Zahlungssystem verfOgbare sichere Datenverbindung 
zwischen einem speziftschen Kunden-Zahlungsmodul 
und dem zugeordneten speziftschen Vertragsmodul- 
Zahlungsmodul aktiviert und den Inhatt der beidsertigen 
Verpffichtung dem speziftschen Zahlungssystem uber- 
gibt, 

in einem 6. Schritt 

der Kunde die notwendigen Ergdnzungen in dem spezi- 
fischen Zahlungssystem vornimmt und die Zahlungsab- 
wicklung mit dem Handler uber das spezrfische 
Kunden-Zahlungsmodul. die Datenverbindung und das 
spezifische Vertragsrnodul-Zahlungsmodul sicher 
artweist 

in einem 7. Schritt 

das spezifische Vertragsrnodul-Zahlungsmodul die 
angewiesene Zahlungsabwicklung an eine spezifische 
Zahlungssystem-DVA des speziftschen Zahlungssy- 



stembetreibers tatigt, 
in einem 8. Schritt 

das Vertragsmodul die spezrfische Zahlungssystem- 
DVA des spezifischen Zahlungssystembetreibers liest, 

5 dessen Eintrage mit dem gespeicherten Inhart der betd- 
seitigen Verpflichtung vergleicht und uber die Datenver- 
' bindung den Handler sicher uber den Status der 
Zahlungsabwicklung informiert, 
in einem 9. Schritt 

10 die Clberweisung von der spezifischen Zahlungssy- 
stem-DVA auf das Konto des Handlers erfolgt. 
[0013] Die Vorteile der Erfindung liegen insbesondere 
in Folgendem: 

is • Der Handler muB die einzelnen spezifischen Zah- 
lungssysteme drrtter Zahlungssystembetreiber 
nicht selbst tntegrieren, da dies (jeweils ein mal) der 
Rnanzdienstleister des Handlers ubernimmt 

• Das Vertragsmodul uberwacht im Interesse des 
20 Handlers die Erf ul lung der sich aus dem beidsertig 

verpf lichtenden Vertrag fur den Kunden ergebende 
Zahlungsverpflichtung, die dieser mit einem dritten 
Zahlungssystembetreiber abwickelt Dor Handler 
erhdlt dadurch die notwendige Sicherhert fur die 
25 Erfuflung der Verpflichtung seinerseits. 

• Speziell fur die Datenverbindung Handler - Rnanz- 
dienstleister ist vorteilhaft, daB der Handler eine 
zertrfizierte Zahlungsbestatigung fur die Erfuflung 
der sich aus der beidsertigen Verpflichtung erge- 

30 benden Zahlungsanweisung des Kunden erhaft, die 
Signatur prufen kann und alle notwendigen ProzeB- 
daten im Vertragsprotokoll mitgeliefert bekommt. 

• Speziell fur die Datenverbindung Handler - Kunde 
besteht eine Kanalsicherhert (bsw. uber einen 

35 SSL), die Handleridentitat und Richtigkeit der 
Bestelldaten ist durch den Kunden prufbar, das Ver- 
tragsprotokoll hat alle notwendigen ProzeBdaten, 
so daB bei Datenausfall in den Basissystemen das 
Vertragsprotokoll aus sich selbst regeneriert wer- 

40 den kann. Der Handler arbeitet stets mit demselben 
neutralen Vertragsprotokoll. unabhdngig von dem 
spezifischen Zahlungssystembetreiber des Kun- 
den. Dieser wiederum kann seine gewohnten Zah- 
lungsanweisungen uber seinen spezifischen 

45 Zahlungssystembetreiber abwickeln und nutzt des- 
sen MOglichkerten vol! aus. 

• Speziell fur die Verbindung Kunde - Rnanzcfienst- 
leister. da die Kundendaten nicht durch das Ver- 
tragsmodul an den Rnanzdienstleister ubergeben 

so werden. Die Zahlungsabwicklung erfolgt direkt zwi- 
schen dem Kunden und dem spezifischen Zah- 
lungssystembetreiber (Eigenschaften des 
spezifischen Zahlungssystems gelten) 

• Alle Datenverbindungen uber Netze sind durch die 
55 Verwendung von Krytographie sicher. 

[0014] Die Erfindung wird als AusfQhrungsbeispiel an 
Hand von 
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Fig. 1 als Schema einer ZahiungsabwicWung 
naher eriautert 

[0015] Nach Fig. 1 wird eine ZahiungsabwicWung not- 
wendig, wenn ein Kunde 1 die Werbung eines Handlers 
2, weicher mrt einem Finanzdienstleister 3 (insbesond- 
ere mit Banken) in Geschaftsverbindung stent, priift, 
eine beidseitige Verpflichtung (z.B. einen Kaufvertrag) 
einzugehen beabsichtigt und die ihn interessierenden 
gewunschten Waren und Zahlungssysteme 4 (z.B. SET, 
EURO-Cash) auswahft. Fur eine Clbertragung von 
Daten sind'der Finanzdienstleister 3 mit dem Kunden 1 , 
der Finanzdienstleister 3 mit dem Handler 2 sowie der 
Kunde 1 mit dem Handler 2 uber Netze 5 (z.B. dem 
Internet) bidirektional durch geschlossene Datenverbin- 
dungen [6a, 6b, 6c] verbunden. Werterhin besteht eine 
Datenverbindung 7 zwischen dem Finanzdienstleister 3 
und dem spezrfischen Zahlungssystem 4 sowie inner- 
halb derer Strukturen (bsw. zu den zugeordneten Kbn- 
ten). Der Finanzdienstleister 3 ist mit dem Kunden 1, 
abhangig vom spezifischen Zahlungssystem 4, uber die 
Datenverbindungen 6a sicher verbunden, ebenso der 
Finanzdienstleister 3 mit dem Handler 2 und dieser mit 
dem Kunden 1 uber die Datenverbindung 6b und 6a. 
Dies kann Hardware basierend Oder Software basie* 
rend durch geeignete Ubertragungssysteme (bsw. uber 
VerschlOsselung mit einem I28brt SSL) erfolgen. Der 
Zahlungsvorgang zwischen dem Kunden 1 und dem 
Handler 2 erfolgt vollstandig innerhalb des spezrfischen 
Zahlungssystems 4. Die Oberwachung und Steuerung 
des Zahlungsvorgangs uber spezifische Zahlungssy- 
steme 4 erfolgt uber das Vertragsmodul 8, weicher uber 
die Finanzdienstleister-EDV 9 auf das Kbnto des Hand- 
lers 2 zugrerfen kann. Dazu stent der Vertragsmodul 8 
des Finanzdienstleisters 3 des Handlers 2 uber je einen 
Zahlungssystemadapter 10 mit den jeweiiigen spezifi- 
schen Vertragsmodul-ZahlungsmoduJen 1 1 des zuge- 
hOrigen Zahlungssystems 4 im Datenaustausch. 
Innerhalb des Zahlungssystems 4 besteht intern ein 
Datenaustausch zwischen dem Kunden 1 und dem 
Finanzdienstleister 3 des Handlers 2 uber ein Kunden- 
Zahlungsmodul 12 und dem Vertragsmodul-Zahlungs- 
modul 11. AuBerhalb des Zahlungssystems 4 besteht 
ein Datenaustausch zwischen dem Vertragsmodul 8 
uber ein Hdndler-Modul 13 und ein Auswahl-Modul 14 
mit dem Kunden 1. Die einzelnen Funktionen zum Ver- 
fahren der ZahiungsabwicWung werden vorteilhaft Qber 
ein separates ProzeBverwaftungsmodul 15, ein Risito- 
managementmodul 16 und ein Handlerverwaftungsmo- 
dul 17 innerhalb des Vertragsmoduls 8 ausgefOhri Die 
Anpassung der einzelnen Protokoile zum Datenaus- 
tausch der Finanzdienstleister-EDV 9 mit denen ande- 
rer erfolgt vorteilhaft uber einen optionalen 
Protokoliwandlermodul 18. Dieses Verfahren der Zah- 
iungsabwicWung unterstOtzt bei dem Handler 2 im Ver- 
tragsprotokoll vorteilhaft ein neutrales Handler- 
Vertragsprotokoll 19 und bei dem Kunden 1 zur Zah- 
iungsabwicWung eine dem spezrfischen Zahlungssy- 
stem 4 spezifische Zahlungsanweisung (20). Innerhalb 



des spezifischen Zahlungssystems 4 wird die Zahiungs- 
abwicWung uber eine spezifische Zahlungssystem-EDV 
21 (b9M. mit einem Zwischenkonto, welches als Sam- 
melkonto dient) vorgenommen. Die spezifische Zah- 
s lungssystem-EDV 21 nimmt die Zahlungsanweisung 
des Kunden 1 bezuglich des Handlers 2 entsprechend 
den spezifischen Bedingungen im spezrfischen Zah- 
lungssystem 4 vor. 

Die ZahiungsabwicWung erfolgt in nachfolgenden 
w Schritten: 

1. Schritt: 

[0016] Durch Auswahl in einem Shoppingsystem des 
is Handlers 2 erfolgt zuerst das Fallen eines Warenkorbes 
durch Kunden 1. Nach der Produktauswahl gibt der 
Kunde 1 dem Handler 2 an, mit welchem Zahlungssy- 
stem 4 er zahlen kann Oder mOchte. Er macht eine 
Preisanfrage bezuglich der verfOgbaren Zahiungssy- 
20 steme 4. Danach erfolgt durch den Handler 2 die Kun- 
deninttialisierung des Kunden 1, falls dieser noch nicht 
initialisiert ist. Es ist vorstellbar, das dies dadurch 
geschieht. indem der Kunde 1 das Auswahl-Modul 14 
als Plug- In oder Applet auf seinen PC iddt und anschlie- 
25 ftend die Zahlungssysteme 4 konfiguriert, die er unter- 
stutzen. Dabei gibt er diese vielleicht schon auf dem PC 
vorhandenen spezrfischen Kunden-Zahlungsmodule 12 
an 

30 2. Schritt: 

[0017] Der Handler 2 tatigt eine Bewertungsarrfrage 
fQr cfie Zahlungssysteme 4, indem er uber die Datenver- 
bindung 6b zu einem Vertragsmodul 8 bei einem 

35 Finanzdienstleister 3 die Kondrtionen fur die gewunsch- 
ten Zahlungssysteme 4 abfragt und dieses sie ihm 
sicher ubermrttert. Dabei arbeitet der Handler 2 stets mit 
demselben neutralen Handler- Vertragsprotokoll 19. Die 
sichere Verbindung wird zwischen dem Vertragsmodul 

40 8 und dem Handler-Modul 13 aufgebaut. Das Vertrags- 
modul 8 uberpruft die Produkt- und Zahlungsanforde- 
rungsinformationen auf ihre Richtigkert (und optional 
der Validrtat des Handlers 2). 

45 3. Schritt: 

[0018] Der Hdndler 2 ubermrttert Qber die Datenver- 
bindung 6c dem Kunden 1 sicher ein Auswahl-Modul 
14, welches, jeweils einzeln fur die gewunschten und 
so verfOgbaren Zahlungssysteme 4, das konkrete Angebot 
des Handlers 2 (Kaufabsichts- und Zahlungsartein- 
schrdnkungen) an den Kunden 1 beinhaftet. 

4. Schritt: 

55 

[0019] Der Kunde 1 wdhft ein einzelnes konkretes 
Angebot des Handlers 2 im Auswahl-Modul 14 aus (der 
Kunde 1 bestatigt den Kauf und das Zahlungssystem 4) 
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und geht damit eine beidseitige Verpf lichtung ein, deren 
Inhalt das Auswahl-Modul 14 sicher uber die Datenver- 
bindung 6c dem Handier 2 und sicher uber die Daten- 
verbindung 6b dem Vertragsmodul 8 Obermittelt, 
welches sie (die Produkt- und Zahlungsanforderungsin- 5 
formationen) auf ihre Richtigkeit (und optional der Vali- 
dity des Handlers 2) uberpruft und bis zur Bestatigung 
der Zahlung unter der eindeutigen ProzeBnummer spei- 
chert AnschlieBend werden die Zahlungs- ProzeB- und 
Produktinformationen an das Clearingsystem des w 
Finanzdienstleisters 3 ubertragen. Es ist vorstellbar, 
daB ebenfatls eine Obertragung der Produktliste mit 
entsprechenden ProzeBinfbrmationen an den Kunden 1 
erfblgt 

15 

5. Schrrtt: 

[0020] Es erfolgt die standardise erte Zahlungsabwick- 
lung durch den Kunden 1 . Er aktiviert uber das Aus- 
wahl-Modul 14 die fur das ausgewahlte spezifische 20 
Zahlungssystem 4 verfugbare (ein spezifisches Kun- 
den-Zahlungsmodul 12 des Finanzdienstleisters 3 Oder 
das eines drrtten Zahlungssystembetreibers) sichere 
Datenverbindung 6a zwischen einem Kunden-Zah- 
lungsmodul 12 und dem zugeordneten spezifischen 2$ 
Vertragsmodul-Zahlungsmodul 11 und ubergibt den 
Inhalt der beidsertigen Verpflichtung dem spezifischen 
Zahlungssystem 4. Optional erfolgt eine Vorinrtialisie- 
rung des Kunden-Zahlungsmodul 12 mit Betrag, Wah- 
rung und weiteren Daten Es ist vorstellbar, daB das 30 
Kunden-Zahlungsmodul 12 des Finanzdienstleisters 3 
selbst stets verfOgbar ist indem es als Plug-In Oder 
Applet auf den PC des Kunden 1 ubertragen wird. 

6. Schritt: 35 

[0021] Der Kunde 1 nimmt die notwendigen Ergan- 
zungen in dem spezifischen Zahlungssystem 4 vor und 
weist die ZahlungsabwicWung mit dem Handler 2 uber 
das spezifische Kunden-Zahlungsmodul 12, die Daten- ao 
verbindung 6a und das spezifische Vertragsmodul-Zah- 
lungsmodul 11 sicher an. Dabei arbeitet der Kunde 1 
mit den gewohnten spezifischen Zahlungsanweisungen 
20 seines gewahtten Zahlungssystemanbieters. Es ist 
vorstellbar, daB der Rnanzdienstleister 3 fur den Kun- 45 
den 1 uberhaupt nicht erkennbar in Erscheinung trrtt 

7. Schritt: 

[0022] Das spezifische Vertragsmodul-Zahlungsmo- so 
dul 1 1 tatigt die angewiesene ZahlungsaJbwicWung uber 
die spezifische Zahlungssystem-EDV 21 an ein Zwi- 
schen konto des spezifischen Zahlungssystembetrei- 
bers. Die Zahlungsantwort des spezifischen 
Zahlungssystems 4 wird vom Vertragsmodul 8 regi- 55 
striert Bei erfbfgreichem Zahlungseingang wird der 
Betrag spater dem (Clearing) Sammeikorrto des 
Finanzdienstleisters 3 gutgeschrieben und in das Kon- 



ten- Oder Verwaltungssystem eingetragen. 

8. Schritt: 

[0023] Das Vertragsmodul 8 liest uber die spezifische 
Zahlungssystem-EDV 21 das Zwischen konto des spezi- 
fischen Zahlungssystembetreibers, vergleicht dessen 
Eirrtrage mit dem gespeicherten Inhalt der beidsertigen 
Verpflichtung und informiert sicher uber die Datenver- 
bindung 6b den Handler 2 uber den Status der Zah- 
lungsabwicWung (Zahlungsbestatigung). Dadurch hat 
das Vertragsmodul 8 die Erfullung der sich aus dem 
beidseitig verpflichtenden Vertag ergebende Zahlungs- 
verpflichtung uberwacht, wobei die Zahlungsabwick- 
lung direkt uber spezifische Zahlungssysteme 4 
erfolgte. Der Handler 2 hat die Gewahr (for deren Erful- 
lung der Rnanzdienstleister 3 burgen kann), daB die 
Zahlungsverpflichtung des Kunden 1 erfullt wurde und 
kann seinerseits die Ware an den Kunden 1 uberetg- 
nen. 

9. Schritt: 

[0024] Die Uberweisung vom Zwischenkonto auf das 
Konto des Handlers 2 erfolgt. Es ist vorstellbar, daB in 
vereinbarten zertiichen Abstanden eine Abarbeitung der 
getatigten Transaktionen erfblgt, bsw. ein Abgleich der 
Eingange auf das Sammeikorrto mit deren Abbuchun- 
gen, eine Fehler- und Sonderfallbehandlung bei Proble- 
men, eine Provisionsabrechnung for den Handler 2, ein 
monarches Versenden der Abrechnung (auch elektro- 
nisch oder auf Papier in unterschiedlichen Detailie- 
rungsgraden mOglich) usw. 

Vorteilhaft ist im 10. Schrrtt: 

[0025] Der Handler 2 erstattet dem Rnanzdienstlei- 
ster 3 eine Gebuhr entsprechend eines Vertrages zwi- 
schen dem Handler 2 und dem Rnanzdienstleister 3. 
So ist es denkbar, daB bei der Uberweisung der Betrage 
an den Handler 2 eine Provision des Rnanzdienstlei- 
sters 3 einbehalten wird, bsw. indem uber das Protokoll- 
wandlermodul 18 die Uberweisungen vom 
Sammelkonto an die Handlertonten (bsw. Girokonto), 
abzOglich der Margen des Clearingbetreibers, initiiert 
werden. So ist es vorteilhaft vorstellbar, daB die einzei- 
nen Kunden 1 abhangig von Zahlungssystem 4 und 
Risikogruppe mrt den realen Kosten der Geldbeschaf- 
fung bewertet werden (incl. Rabat durch Volumen und 
Margen). Diese kOnnen in Sammelkonten zusammen- 
gefaBt, mrt den Systembetreiberkosten (ca. 0,1%) 
beaufschlagt sowie mit weiterberechneten Kosten und 
auf die einzelnen Handlerkonten aufgeteiK werden. 
[0026] BezQglich der Gewahrleistung einer sicheren 
Datenverbindung 6a, 6b, 6c ist es vorstellbar, daB vor- 
bekannte kryptographische Systeme in der nachfolgen- 
den Art verwendet werden: 

Der Handier 2 sendet ein teifweise verschlussettes 
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Datenpaket (bsw. bestehend aus: verschlussefte Ware, 
unverschlusselte Ware, Zahlungstyp, eindeutige Pro- 
zeBnummer, Hashwert der verschlOsserten Ware, Regi- 
ster nummer des Handlers 2 und dessen Signatur, 
Public Key des Handlers 2) an den Kunden 1 (ohne 5 
Kundendaten und Warendaten). AnschlieBend pruftder 
Kunde 1 die Transaktionsdaten auf Identrtat (bsw. prut- 
bar mit einem zertrfizierten Public Key) und fuhrt eine 
Uberprufung des verschlusselten Wareninhalts (bsw. 
durch Hash-Erzeugung uber dem lesbaren Wareninhalt w 
und Vergleich mit dem mitgelieferten Hash des ver- 
schlusselten Wareninhalts). AnschlieBend sendet der 
Kunde 1 das Datenpaket an das ProzeBverwaltungsmo- 
dul 15 des Finanzdienstleisters 3 (gegebenenfalls mit 
Angaben zum Zahlungstyp erganzt). Der Rnanzdienst- 15 
leister 3 selbst erhait nur eine ProzeBnummer. Die 
Transaktion wird vom Vertragsmodul 8 angenommen 
und das eigentiche spezrfische Vertragsmodul-Zah- 
lungsmodul 11 aufgerufen, wobei die ProzeBnummer 
wertergelertet wird. Das spezrfische Vertragsmodul- 20 
Zahlungsmodul 1 1 baut spezif isch eine sichere Verbin- 
dung 6a zum spezif ischen Kunden-Zahlungsmodul 12 
auf. AnschlieBend erfolgt die Abwicklung der Zahtung 
(zwischen dem spezifischen Zahlungssystembetreiber 
3 und dem Kunden 1). 2 s 
Das ProzeBverwaltungsmodul 15 erhait als Ergebnis 
nur, daB die Zahlung mit der entsprechenden ProzeB- 
nummer abgewickelt wurde Oder nicht, im letzen Fail 
erfolgt eine entsprechende Fehlermeldung. Die Eigen- 
schaften des entsprechenden Zahlungsmittels des spe- 30 
zrfischen Zahlungssystems 4 (z.B. Anonym rtat) Wefoen 
uneingeschrankt erharten. Nach erfolgter Zahlung sen- 
det das ProzeBverwaltungsmodul 15 die ProzeBnum- 
mer und die Bestatigung der eingegangenen Zahlung 
an den Handler 2. 35 

Verwendete Bezugszeichen 
[0027] 

40 

1 Kunde 

2 Handler 

3 Finanzdienstleister 

4 Zahlungssystem 

5 Netz 45 

6 [a, b, c] geschlossene Datenverbindung 

7 Datenverbindung 

8 Vertragsmodul 

9 Finanzdienstleister-DVA 

10 Zahlungssystemadapter so 

1 1 spezif isches Vertragsmodul-Zahlungsmodul 

12 spezif isches Kunden-Zahlungsmodul 

13 Hdndler-Modul 

14 Auswahl-Modul 

15 ProzeBverwaltungsmodul 55 

16 Risikomanagementmodul 

17 Hdndlerverwaltungsmodul 

18 Protokollwandlermodul 



1 9 Handler- Vertragsprotokoll 

20 spezrfische Zahlungsanweisung 

21 spezrfische Zahlungssystem-DVA 

Patentanspruche 

1. Verfahren zur rechnergestutzten Zahlungsabwick- 
lung uber Zahlungssysteme, bei welchem ein 
Kunde (1) uber eine Datenverbindung (6c) die Wer- 
bung eines Handlers (2) pruft, eine beidseitige Ver- 
pflichtung einzugehen beabsichtigt und die ihn 
interessierenden gewOnschten Waren und Zah- 
lungssysteme (4) auswahft, dadurch gekenn- 
zeichnet, daB 
in einem 1 . Schritt 

der Kunde (1) seine gewOnschten Waren und Zah- 
lungssysteme (4) dem Handler (2) uber die Daten- 
verbindung (6c) mitteirt und danach durch den 
Handler (2) die Kundeninitialisierung des Kunden 
(1) erfolgt, 
in einen 2. Schritt 

der Handler (2) uber eine Datenverbindung (6b) zu 
einem Vertragsmodul (8) bei einem Finanzdienst- 
leister (3) die Kbndrtionen fur die gewOnschten Zah- 
lungssysteme (4) abfragt und dieses sie ihm sicher 
ubermrttert, 
in einem 3. Schritt 

der Handler (2) uber die Datenverbindung (6c) dem 
Kunden (1) sicher ein Auswahl-Modul (14) ubermrt- 
tert, welches, jeweils einzeln fur die gewOnschten 
und verfOgbaren Zahlungssysteme 4, das konkrete 
Angebot des Handlers (2) an den Kunden (1) 
beinhaftet, 
in einem 4. Schritt 

der Kunde (1) ein einzefnes konkretes Angebot des 
Handlers (2) im Auswahl-Modul (14) auswahft und 
damit eine beidseitige Verpfiichtung eingeht, deren 
Inhatt das Auswahl-Modul (14) sicher Ober die 
Datenverbindung (6c) dem Handler (2) und sicher 
uber die Datenverbindung (6b) dem Vertragsmodul 
(8) ubermitteit, welches sie auf ihre Richtigkeit 
uberpruft und urrter der eindeutigen ProzeBnum- 
mer speichert, 
in einem 5. Schritt 

das Auswahl-Modul (14) die fur das ausgewahlte 
spezrfische Zahlungssystem (4) verfQgbare sichere 
Datenverbindung (6a) zwischen einem spezifi- 
schen Kunden-Zahlungsmodul (12) und dem zuge- 
ordneten spezrfischen Vertragsmodul- 
Zahlungsmodul (11) aktrviert und den Inhatt der 
beidseitigen Verpffichtung dem spezrfischen Zah- 
lungssystem (4) ubergibt 
in einem 6. Schritt 

der Kunde (1) die notwendigen Erganzungen in 
dem spezrfischen Zahlungssystem (4) vornimmt 
und die ZahlungsabwicWung mft dem Handler (2) 
uber das spezrfische Kunden-Zahlungsmodul (12), 
die Datenverbindung (6a) und das spezrfische Ver- 
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tragsmodul-Zahlungsmodul (11) sicher anweist, 
in einem 7. Schritt 

das spezifische Vertragsmodul-Zahlungsmodul 
(11) die angewiesene ZahlungsabwicWung an eine 
spezifische Zahlungssystem-DVA (21) des spezrfi- 5 
schen Zahlungssystembetreibers tatigt, 
in einem 8. Schritt 

das Vertragsmodul (8) die spezifische Zahlungssy- 
stem-DVA (21) des spezifischen Zahlungssystem- 
betreibers liest. dessen Eintrage mit dem w 
gespeicherten Inhatt der beidseitigen Verpf lichtung 
vergleicht und uber die Datenverbindung (6b) den 
Handler (2) sicher uber den Status der Zahlungsab- 
wicklung irrformiert, 

in einem 9. Schritt is 
die Uberweisung von der spezifischen Zahlungssy- 
stem-DVA (21) auf das Konto des Handlers (2) 
erfolgt. 

2. Verfahren zur rechnergestutzten Zahlungsabwtck- 20 
lung uber Zahlungssysteme nach Anspruch 1, 
dadurch gekermzeichnet, 

daft der Handler (2) dem FinanzdienstJetster (3) 
eine GebOhr entsprechend eines Vertrages zwi- 
schen dem Handler (2) und dem Finanzdienstlei- 25 
ster (3) erstattet 

3. Verfahren zur rechnergestutzten Zahlungsabwick- 
lung uber Zahlungssysteme nach einem der 
Anspruche 1 Oder 2, dadurch gekennzeichnet, 30 
daB zur Gewahrtetstung einer sicheren Datenver- 
bindung (6a), (6b), (6c) kryptographische Systeme 
verwendet werden, indem 

im (3) Schritt 

der Handler (2) ein teilweise verschlusseltes Daten- 35 
paket an den Kunden (1) sendet, 
im (4) Schritt 

der Kunde (1) die Transaktionsdaten auf Identital 
pruft und eine UberprOfung des verschlussetten 
Wareninhatts durchfutirt, nach dem Eingehen der 40 
beidseitigen Verpf ichtung der Kunde (1) das 
Oatenpaket uber den Handler (2) an das ProzeG- 
verwaltungsmodul (15) des Rnanzdienstleisters (3) 
sendet. der Finanzcfienstfeister (3) selbst nur eine 
ProzeSnummer erhaft, die Transaktion vom Ver- 4s 
tragsmodul (8) angenommen und das eigentiiche 
spezifische Vertragsmodul-Zahlungsmodul (11) 
aufgerufen wird, wobei die ProzeBnummer weiter- 
gelertet wird, 

im 6. Schritt so 
die AbwicWung der Zahlung zwischen der spezifi- 
schen Zahlungssystembetreiber und Kunden (1) 
entsprechend der Datensicherheit des spezifischen 
Zahlungssystems (4) erfolgt das ProzeBverwai- 
tungsmodul (15) nur als Ergebnis erhdlt, da6 die ss 
Zahlung mit der entsprechenden ProzeGnurrtmer 
abgewtckett wurde Oder nicht wobei im letzen Fall 
eine entsprechenden Fehfermeldung erfolgt, nach 



erfolgt er Zahlung das ProzeRverwartungsmodul 
(15) die ProzeBnummer und die Bestatigung der 
eingegangenen Zahlung an den Handler (2) sen- 
det. 
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